The present invention relates to the field of trust management in a distributed control environment. More specifically, one embodiment of the invention provides for management of trust relationships among code segments to be executed inside a trust boundary.
No practical computer can be completely secure. If a computer system operator were to distrust all software not personally written, the operator could erase all the software on a computer system running in a room with one door secured with an around-the-clock guard and no eternal connections to the machine and then write secure code from scratch. The system is still not completely secure, since the computer system might have been manufactured with an interface to an implanted radio transceiver, thus leaving the computer system vulnerable. If a security mechanism is to be workable, the designer of the security mechanism must assume a base level of trust of some aspect of the computer system.
This base level of trust can vary depending on the use of the computer system and could range from complete trust of everything, to trust of only the equipment and data found in a locked building and purchased from a reputable source, or trust of only a known good microprocessor. Wherever this base level of trust is set, it defines a "trust boundary" separating that which is trusted and that which is not trusted. A trust boundary envelops computer resources, data and people so that unauthorized and untrusted users, programs and data processing systems are prevented from accessing resources of a computer system or reading or modifying the data stored by that computer system.
It is important to note that, when it comes to complex computer systems, trust is not just a matter of one's good faith or intentions. An otherwise trustworthy person may cause great damage to a computer system by making a mistake or running a program with bugs, viruses or Trojan horses. For this reason, robust computer systems are designed with the "principle of least authority" in mind. That principle dictates that a user or program should be granted only the authority needed to perform the task at hand and no more, to prevent intended and unintended ill effects.
With early mainframe computers, security was simple. The trust boundary was the building housing the computer, no communications lines ran outside the building and only trusted personnel were granted physical access. Personnel not intimately involved in the data processing operations where considered untrusted users and thus outside the trust boundary. An untrusted user having legitimate business with the mainframe had to go through a technician who handled tasks for the user.
With timesharing machines, users had access to the computer system directly via terminals, but access was controlled by passwords to inhibit unauthorized access and the operating system of the computer system included software protection to prevent unintentionally destructive actions by the users. For example, even an authorized user running a misbehaving program could not destroy the data files of another user or crash the computer system. (At least that was the ideal goal of timesharing machine designers.)
Today, desktop computers are proliferating and also require security. The typical method of securing a desktop computer from unauthorized use is to physically secure it in a room or office building. Even if the computer has connections to an external network, the computer is secured by the fact that the operating system of the desktop computer does not have any code which is controllable by an outside person or machine. The assumption that the operating system does not have a portal accessible from the outside is invalid when an authorized person runs a program knowingly or unknowingly which executes code which allows such access.
Misbehaving programs are likely to become more commonplace as more people use computers who do not understand how computers work, since today's user interfaces encourage programs to be run transparently and without specific user initiation or supervision. Furthermore, as more people connect to open networks such as the Internet, more programs of unknown origin find their way onto their machines and are executed with ill effects.
One way to prevent misbehaving programs is to disallow the use of external programs altogether. If a computer is built without any mechanism for loading a program from an external source and then executing that program, then no misbehaving programs will affect its operations (except for misbehaving programs which have been within the computers trust boundary all along). However, this limits the usefulness of the computer and the benefits of improved technology, ease-of-use transparency and other advantages of personal computers.
Such a computer could not even fully browse today's World Wide Web (the global web of hyperlinked documents and servers operating over the Internet; hereinafter "the Web"). Many Web sites have pages which require Web applet execution for proper viewing. A Web applet is provided by the server of the page being viewed and is a code snippet which is executed by the browser user's computer at the request of the browser. The fact that the applet is executing is often totally unknown to the user, until an improper or malicious applet causes the computer to start acting erratically, the applet transmits the user's private data to the outside world, deletes the user's data, or uses up excessive computing resources.
To prevent the harm causable by misbehaving programs, the computer system must have a security mechanism. One such security mechanism for applet execution is the security provided by the Java.TM. runtime system developed by Sun Microsystems of Mountain View, Calif. and licensed to many software developers. The Java.TM. runtime system is used in connection with a computer connected to the Internet. For example, where a Java.TM.-compatible Web browser encounters a Web page containing a Java.TM. applet, the browser might download and execute the applet without asking the user. The Internet should be outside the user's trust boundary, since the user does not control and cannot trust every program on the Internet. Therefore, there is a risk that the user will encounter an applet whose goal or unintended effect is to harm the user's system. To prevent this harm, the browser is programmed to ignore Java.TM. language statements which may be used for unauthorized access. For example, the browser might be set so that no applet is able to read preexisting files on the user's system and is only able to modify files which are created by the applet itself. If an applet is obtained by the user from a reliable source, these restrictions may be unduly limiting.
Even if an applet system were devised where dangerous programs could be executed if a user is willing to accept the increased risk in exchange for increased functionality, a software provider will often apply the most stringent limits on their software to avoid problems with the most risk adverse customers. Thus, if the constraints are set in advance by the application, the applets will be unduly limited to the lowest level of functionality and if the constraints are set by the software provider, the applets will be unduly limited to functionality constraints of the provider's strictest customer. As a corollary to the Principle of Least Authority, in order for a program to be useful, it cannot be constrained to the point where it is not given the authority to perform its assigned tasks.
From the above it is seen that an improved trust management system is needed where trust in program code can be varied for a user given the user's particular circumstances and the source of the program code.